In a Third Generation Partnership Project (3GPP) wireless network, the radio resource control (RRC) protocol establishes, maintains, and releases the RRC connection between a user equipment (UE) and the universal mobile telecommunications system (UMTS) terrestrial radio access network (UTRAN). The RRC protocol also establishes, reconfigures, and releases Radio Bearers (RBs) and Signaling Radio Bearers (SRBs).
Various RRC procedures (e.g., RB Setup, RB Release, and RB Reconfigure) may reconfigure the radio access bearer (RAB), RB/SRB, transport channel, and/or physical channel parameters in the UE from a first or source configuration to a second or target configuration. The reconfiguration is typically triggered by data activity/inactivity of existing radio bearers or setup/release of new radio bearers.
For some reconfigurations, the UE and the network change configuration at the same time to avoid a misalignment between which configurations the UE and the network are using. A misalignment of configurations may result in the UE and the network being unable to communicate. Such reconfigurations use synchronized RRC procedures. An example of a conventional synchronized RRC procedure is illustrated in FIG. 1.
FIG. 1 is a signaling diagram illustrating an example method of a conventional synchronized RRC procedure. In general, the network calculates an activation time and sends the activation time to the UE. The network includes margins in the calculation to account for various types of delays.
At step 52, radio network controller (RNC) 40 receives a trigger for a reconfiguration. RNC 40 sends reconfiguration messages to UE 10 and radio base station (RBS) 20 containing the new configuration at step 54. The messages include an activation time, specifying the connection frame number (CFN) when UE 10 and RBS 20 should switch to the new configuration. RNC 40 calculates when UE 10 could be ready to switch to the new configuration and sets the CFN accordingly.
To minimize the risk of a dropped call because of a state misalignment between UE 10 and RBS 20, RNC 40 allows for sufficient time for the UE to receive the reconfiguration message and prepare to switch configurations at the specified CFN. Thus, RNC 40 may typically estimate the activation CFN conservatively to account for UEs 10 that may be in poor radio conditions, to account for large possible fluctuations in transport network delay, etc. The result is a long activation time in which all reconfigurations suffer from a long delay that is only needed in a small percentage of reconfigurations.
Enhancements to synchronized RRC procedures may include media access control (MAC) layer handshake procedures. Such procedures may be performed without a high speed signaling channel (HS-SCCH) order. An enhancement may include exchanging a backup CFN at which time the switch should occur if the handshake fails. For example, a MAC layer handshake may send an offset and a backup CFN in a downlink RRC reconfiguration message. When the UE is ready to switch to the new configuration, the UE sends an uplink MAC Control Information (MCI). At the hybrid automatic repeat request (HARQ) acknowledgement (ACK) to the MCI, both the UE and the network calculate the activation time by adding the offset to the current CFN. An advantage is that this approach does not add margins for air interface delays. An example is illustrated in FIG. 2.
FIG. 2 is a signaling diagram illustrating an example method of a conventional synchronized RRC procedure using a MAC layer handshake. In general, UE 10 sends an MCI when UE 10 is ready to switch to the new configuration. UE 10 and the network then calculate the activation time based on the time for the HARQ ACK to the MCI and the offset sent in the RRC message. This enhancement enables a faster switch to the new configuration. If the handshake fails for some reason, then UE 10 and the network will switch to the new configuration at the backup activation time.
If the MCI or its HARQ ACK is lost over the air, then UE 10 retransmits the MCI according to the conventional HARQ mechanism. The activation time is not determined until the HARQ ACK to the MCI is successfully received. If UE 10 has not received the ACK to the MCI after a maximum number of retransmissions, then UE 10 will fall back to the backup CFN. Similarly, if RBS 20 has not received an MCI for the reconfiguration, RBS 20 will switch to the new configuration at the backup CFN.
A problem with the MAC level handshake is that if the NodeB has received the MCI but the downlink HARQ ACK does not reach the UE, then the UE and the network may be misaligned with respect to the switch CFN. For example, the network will calculate a switch CFN based on the MCI ACK and the offset, but the UE will switch at the backup CFN.
Another problem is that if the UE receives the RRC reconfiguration message late (i.e., at a time close to the backup CFN), then the UE and the network may also be misaligned regarding which activation time should be used (e.g., the calculated activation time from the handshake or the backup activation time).